Business processes often interact with many different back-end application systems and groups of people that typically are distributed across many geographies. For example, an enterprise typically has many facilities, with each hosting applications used by workers that have specific tasks to be performed in a given facility. Rarely is there a single central data center that provides all of the computing resources needed for a business to function.
One approach for providing resources across various geographies has involved decentralized distributed computing. Decentralized distributed computing, in general, relies on wide area networking to provide connectivity between different facilities. Unfortunately, wide area networking typically has reduced bandwidth, latency, and is more costly to maintain than local area networking.
Accordingly, it typically is more efficient and reliable to process data locally, e.g., on a local area network (LAN), than across a wide area network (WAN). But this processing arrangement creates a technical challenge for enabling a business to realize the benefits of Business Process Management (BPM) when an intimate knowledge of the physical infrastructure of its enterprise is lacking or completely absent.
The concept of process orchestration typically employs the use of an orchestration engine. Commercially available BPM orchestration engines are typically designed such that a business process's state is managed in a single location by a single orchestration engine. This implies that orchestrating services that interact with remote applications require a stable and reliable wide area network that has sufficient bandwidth and redundancy to handle the loading factors that often occur when BPM systems handle large volumes of data.
Furthermore, significant knowledge of the physical infrastructure within an enterprise often is not fully understood by business users who rely upon BPM process modeling as a methodology to create business-oriented solutions in a rapid fashion. Unfortunately, current Business Process Management Suite (BMPS) products that are commercially available do not remove the technicalities associated with how a process will be deployed and execute at the time the process is defined.
Thus, it will be appreciated that there is a need in the art for techniques that improve process routing and/or execution. Moreover, there also is a need in the art for techniques that provide location transparent process execution, for example, so that data and services may be accessed across a plurality of geographies effectively, efficiently, and/or with a reduced knowledge of the exact technical makeup of the enterprise and/or its network architecture.
One aspect of certain example embodiments of this invention relates to location transparent distributed process execution as enabled by a suitably configured protocol (e.g., JMS messaging). In certain example embodiments, a process engine may be insulated from the step invocation location by utilizing a queuing/publish-subscribe behavior (e.g., as found in JMS messaging) to execute transitions between process steps.
An aspect of certain example embodiments relates to a BPM process engine capable of distributing the execution of a business process and insulating the location of where process steps execute via a suitable protocol (e.g., via JMS messaging).
Another aspect of certain example embodiments relates to reducing the need for specific knowledge about the location of where steps of a business process execute and/or the physical infrastructure that comprises the resources employed by the enterprise, on the part of a person authoring a business process and/or the process engine itself.
A further aspect of certain example embodiments relates to a reduced need for binding a process to a specific process orchestration engine, thus allowing for the execution of steps to be distributed throughout the enterprise and, in turn, allowing business processes to execute more efficiently in a distributed computing environment.
Yet another aspect of certain example embodiments relates to a significantly horizontally scalable and easy to manage architecture.
In certain example embodiments, a method of configuring a network is provided. A service-oriented integration server including a process engine is provided. At least one physical server is connected to the network. Each said physical server includes an instance of the integration server, and each said instance of the integration server includes an instance of the process engine. A messaging layer for use with the network is provided. At design time, a process is modeled so as to generate a process model, with the process model defining at least one activity associated with the process and at least one step associated with each said activity; and each said activity is assigned to a logical server such that, at deployment time, any executable artifacts needed by an instance of the process engine are generatable. Runtime artifacts are generated from the design time process model. This process includes the steps of generating at least one package from the design time process model, with each said package corresponding to one said logical server and including at least one trigger and a process fragment file, each said trigger being responsible for subscribing to process transition document messages to be routed to the instance of the process engine installed on the corresponding instance of the integration server and for filtering process transition document messages published to the messaging layer, the process fragment file defining only those process steps that are associated with the corresponding logical server; and creating two queues on the messaging layer, with a first queue to process messages that trigger new process instances and a second queue to accommodate transitions between process steps of the process model. Each said package is deployed to a physical server. The package is deployed as a runtime asset for the corresponding instance of the process engine. The process transition document messages are published by the process engine, with each said process transition document message including routing data as a part of the message itself for routing the message. The process engine is configured to provide location transparent routing and process execution via process transition document subscription and filtering.
In certain other example embodiments, there is provided a method of operating a network including at least one physical server and a messaging layer, with each said physical server including an instance of a service-oriented integration server provided to the network, and with each said instance of the integration server including an instance of a process engine. At design time, a process model corresponding to a process to be executed is generated. The process model includes at least one activity associated with the process and at least one step associated with each said activity. Runtime artifacts are generated from the process model. The runtime artifacts comprise at least one deployable unit of executable logic for execution on a corresponding instance of the process engine, a first queue to process process transition documents that trigger new process instances, and a second queue to accommodate transitions between steps of the process model. Each unit of executable logic is deployed to a physical server as a runtime asset for the corresponding instance of the process engine. An instance of the process is initiated according to the process model. A process transition document is published. The process transition document is populated by the process engine with routing data as a part of the message itself for routing the message. Each instance of the process engine subscribes to the process transition documents to be routed to the corresponding instance of the process engine installed on the corresponding instance of the integration server and filters other process transition documents published to the messaging layer. After a step in the process model is executed, a new process transition document is published to cause a next step in the process model to be executed. The process is routed and executed in a location transparent manner.
According to certain example embodiments, a computer-mediated network is provided. A service-oriented integration server includes a process engine configured to provide location transparent distributed execution of a process conforming to a user-defined process model. The process model defines at least one activity associated with the process and at least one step associated with each said activity. A messaging layer for the network is provided. At least one physical server is provided. Each said physical server includes an instance of the integration server. Each said instance of the integration server includes: an instance of the process engine and runtime artifacts generated at design time based on the design time process model. The runtime artifacts include at least one package, with each said package corresponding to one said logical grouping of one or more activities; and two queues provided for the messaging layer, a first queue to process messages that trigger new process instances and a second queue to accommodate transitions between process steps of the process model. Each said instance of the integration server also includes at least one trigger, with each said trigger being responsible for subscribing to process transition document messages to be routed to the instance of the process engine installed on the corresponding instance of the integration server and for filtering process transition document messages published to the messaging layer; and a process fragment file, with the process fragment file defining only those process steps that are associated with the corresponding logical server. The process transition document messages are published by the process engine, with each said process transition document message including routing data as a part of the message itself for routing the message.
According to certain other example embodiments, there is provided a process engine for use across instances of a service-oriented integration server provided to a network having a messaging layer. The process engine is configured to execute a process in accordance with a process model defined at design time so as to include at least one activity associated with the process and at least one step associated with each said activity. Each instance of the process engine comprises runtime artifacts generated from the process model that correspond to a deployable unit of executable logic for execution on the instance of the process engine; a publishing service configured to publish a process transition document, with the process transition document being populated by the process engine with routing data as a part of the message itself for routing the message; a subscription service configured to subscribe to the process transition documents to be routed to the corresponding instance of the process engine installed on the corresponding instance of the integration server; and a filtering service configured to filter other process transition documents published to the messaging layer. The messaging layer includes two queues generated from the design time process model, including a first queue to process transition documents that trigger new process instances, and a second queue to accommodate transitions between steps of the process model. After a step in the process model is executed, the publishing service is configured to publish a new process transition document to cause a next step in the process model to be executed. The process is routed and executed in a location transparent manner.
It will be appreciated that the term “service” corresponds to any suitable combination of hardware, software, firmware, and/or programmed logic circuitry.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.